One popular form of an information retrieval system for managing computerized records is a relational database management system such as DB2™, manufactured by International Business Machines Corporations. Between the actual database (i.e., the data as stored for use by a computer) and the users of the database is a software layer known as the relational database management system (“RDBMS” or “DBMS”). The DBMS is responsible for handling all requests for access to the database, shielding the users from the details of any specific hardware or software implementation. Using relational techniques, the DBMS stores, manipulates and retrieves data in the form of table-like relations typically defined by a set of columns or attributes of data types and a set of rows (i.e., records or tuples) of data. The columns may further comprise restrictions on their data content (i.e., valid domains) and may be designated as a primary key or unique identifier for the relation or a foreign key for one or more other relations.
Log catchup is a technique commonly used in the database industry during certain online operations whereby a database remains available to users online while undergoing operations such as: online create index (OLIC) or online reorganize index (OLIR), online reorganize table or tablespace. Typically, online operations employing the log catchup technique replicate the database target to be built or reorganized online, creating a separate shadow object. This shadow object is then processed in accordance with the build or reorganize operation while the original database target remains available for read/write access by concurrent readers/writers. One or more logs of operations by the concurrent reader/writers are maintained by the database system for subsequent application to catch up the shadow object to the currency of the original database target. Once caught up, the original database is locked for access briefly as the shadow object is made available for use.
There could potentially be considerable logs to be processed and significant amount of physical input/output operations (I/Os) involved, especially when the target to be built or reorganized is large and requires many hours to be (re)built. Furthermore, the log is frequently flushed to disk, and in fact, can be archived to longer term storage (e.g., tape). Thus log catchup is inherently limited by the speed of these storage devices. Also, the logs of operations normally contain log records for the whole database, and not just for the target object of interest. Log catchup requires reading through each log record accumulated during the period when an online operation is started until the shadow object becomes as current as the target.
Thus, using log catchup can potentially encounter a number of problems. For example, if there are too many update activities on the database, log catchup may never catch up. Objects that need to be built or rebuilt online are usually large size and thus make log catchup an inherently long process, and one that is computationally expensive due to all the physical I/Os involved. Log catchup can be a long and slow process even when there fewer update activities on the target object since logs are not just for the shadow object.
What is therefore needed is a system and associated method for improving the performance of the log catchup function with respect to speed and efficiency. The need for such a system and method has heretofore remained unsatisfied.